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BACKGROUND OF THE INVENTION 

1. FIELD OP THE INVENTION! 

The present invention relates to a method of ao- simulating 
5 a digital olroult . Suoh a method may be used as part of 
the design and manufacturing process of Integrated 
circuits, for example of VLSI type, 

2. DESCRIPTION OF THE RELATED ART: 

10 Non- trivial digital hardware olroult s are usually 
designed using a synthesis -based approach where the 
circuit is descrihed in a Hardware Description Language 
(HDL) and then synthesised Into hardware using a synthesis 
tool. VHDL (for example as disclosed in IEEE Computer 

15 Society, "IEEE Standard VHDL Language Reference Manual" 
New York. USA, March 1988. IEEE Std 1076-1987 and IEEE 
Computer iSociety, ''IEEE Standard VHDL Language Reference 
Manual' New York, USA, June 1994* IEEE Std 1076-1993) 
and Verilog HDL (for example as disclosed in IEEE computer 

20 Society, 'IEEE Standard Hardware Description Language 
Based on the Verilog Hardware Description Language . " New 
York, USA 1996, IEEE Std 1364-1995) are commonly used 
hardware description languages. However^ as circuit 
complexity continues to increase, there is a trend to use 
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higher-level hardware description languages, usually 
based on programming languages such as C (for example as 
disclosed in, Brian 

W. Kernighan and Dennis M. Ritohie^ ""The C Programming 
5 Language. Prentioe-^Hall, USA, second edition, 1966") 
and C++ (for example as disclosed in B jarne Stroustrup, 
""The C++ programming language," Addison-Wesley series 
in computer science, Addison-Wesley, Reading, MA, USA) 
instead of register transfers. 

10 

Such languages allow the design of hardware In terms of 
algorithms. High-level synthesis tools (for example as 
disclosed in Daniel Gajski, Nikll Dutt^ Allen Wu, and 
Steve Lin^ *High-Level Synthesis, introduction to Chip 

15 and System Design.' Kluwer Academic Publishers, 
Boston/Dordrecht /London, 1992) are then used to generate 
lower level HDL descriptions from the given 
algorithm- level descriptions. Similarly to software 
design, the use of a high-level language usually results 

20 in shorter design times. 

In some systems, the high-level HDL used is simply a well 
known programming language. For instance System C (for 
example as disclosed in Synopsys Inc. Overview of the 
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Open System C Initiative," datasheet available on the 
Internet from vww.sys tema.org, 1999) uses C-i-'i^ as a system 
description language. In other cases, a programming 
language with extensions relevant to hardware design is 
5 used. Examples of such systems Include the Tangram 
system (as disclosed in K. van Berkel, J. Kessel, M. 
Roncken, R* Saeljs, andF* Schalij, ''The VLSI -Programming 
Language Tangreun and its Translation into Handshake 
Circuits' « Proceeding of the European Design Automation 
Q 10 Conference (BDAC 91), pages 384-389, Amsterdam, February 

1991 , IEEE, IEEE Computer Society Press and Rees van Berkel, 
:P 'Handshake Circuits'' , volume 5 of Cambridge International 

iy Series on Parallel Computation, Cambridge University 

g Press, Cambridge, UK, 1993) and the Bach system (as 

Ipil 15 disclosed in Akihlsa Yamada, Koichi Nishlda, Ryoji 

f"; Sakurai, Andrew Kay, Toshio Nomura and Takashi Kambe, 

Q " ''Hardware synthesis with the BACH system" " International 

Symposium on Circuits arid Systems, 1999 and in 6B 
231724S). 

20 

The language used by the Bach hardware compiler extends 
the C language with (amongst other features) constructs 
for expressing explicit parallelism and synchronous 
communication. The Bach language is based on the 
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Coznmunlcatlng Sequential Prooes&es (CSP) model, which Is 
disclosed in C.A.R. Hoare, "Communicating sequential 
processes-" Communications of the ACM, 21 (8)s666-677^ 
August 1978 and C.A.R. Hoare, "Communicating Sequential 
5 Processes.'' Prentice-Hall International, Englewood 
Cliffs (NJ), USA, 1990, first edition published in 1985 
by Prentice -Hall and which is a model of computation which 
supports concurrency ♦ The Tangram language is also based 
on CSP. 

10 

Another important advantage of using a high-level HDL is 
faster simulation speeds due to the level of abstraction 
of the design description ♦ Very fast simulation speeds 
can also be achieved by compilation based simulation {see 

15 for example L.T. Wangi N.E. Hoover, E.H* Porter, and J, J, 
Zaslo. *SSIM: A software levelised oomplled-code 
simulator"^ Proceeding of th© 24*** Design Automation 
Conference^ pages 2-6, IEEB,ISEB Computer Society Press, 
1987) where the hardware description is compiled into an 

20 executable format rather than interpreted by the 
simulation engine. In the case of using a sequential 
programming language (such as C++) as a HDL, a hardware 
description can be compiled and simulated simply by using 
a standard compiler for the particular language* If th© 



00R00416 

- 5 - 



programming language used is extended with hardware 
design relevant features suah as parallelism, then a 
hardware description can be converted Into a sequential 
program before being compiled. For example, in the 
5 Tangram system, a hardware description can be converted 
into a C program as disclosed in Kees van Berkel, 
"•Handshake Circuits," volume 5 of Cambridge University 
Press, Cambridge, UK, 1993. Also, JP 1121939 describes 
a simple mechanism for converting CSP features Into a 
10 sequential language. 

In systems comprising of one or more components, every 
component may be described in a language chosen for its 
particular strengths and expressiveness. For example, 

15 a hardware description language Is used for hardware 
components and a software programming language is used 
for software components. It Is therefore very common 
that the components in a system are described in several 
languages. Figure 4 of the accompanying drawings shows 

20 an exzimple of such a system description. The complete 
system description comprises a plurality of component 
model descriptions which communicate with each other. 
The Bach C Language mentioned hereinbefore is used at 2 
and 3 to provide descriptions of a demodulator component 
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and an error correction decoder component. The VHDL 
language mentioned hereinbefore is used at 4 and 5 to 
describe a RAM (random access memory) component and a Fast 
Fourier Transform (FPT) component. The C Language is 
used at 6 to describe a test bench component. 

Since the verification of such a system is an essential 
part of its design process, it is required that the 
verification, or simulation, is fast as a lot of 
simulation data may have to be processed. This 
simulation process Is often referred to as co- simulation 
because of the heterogeneous nature of the system. The 
different system component models need to communicate 
with each other during co- simulation, and known methods, 
such as that disclosed in US 5335191, can be used. One 
method for the co- simulation of a hardware component 
designed in a high-level HDL is to synthesise the hardware 
description into a lower-level HDL using a high-level 
synthesis tool or simulation engine 8 as illustrated in 
Figure 2 of the accompanying drawings, and then co- 
simulate the low-level description using the hardware 
simulation tool. However, this method does not take 
advantage of the fact that a high-level description can 
be used for simulation, and has the following 
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disadvantages : 

(a) synthesis time overhead; 

(b) slower eimulation due to the use of a lower- level 

5 HDL; 

(c) applicable only to syntheslsable descriptions. 

Hardware simulators presently available allow the 
simulation of models described in different HDLe . as well 

10 as foreign models , that is , models described using means 
other than the HDLs understood by the simulator. For 
instance^ the latest standard of VHDL {for example as 
disclosed in IEEE Computer Society, "IEEE Standard VHDL 
Language Reference Manual,* New York, USA, June 1994. IEEE 

15 Std 1076-1993) allows the specification of foreign 
entitles • The Synopsys VSS simulator (as disclosed in 
Synopsys Inc. VSS Reference Manual, USA, 1998) provides 
a C Language Interface (CLI) (as disclosed in Synopsys 
Inc. VSS Interfaces Manual, USA. 1998 ) for the 

20 implementation of foreign entities using the C language • 
Similarly the Model Technology ModelSim simulator {as 
disclosed in Model Technology Inc , ModelSim SE/EE User ' s 
Manual. USA. 1999) provides a Foreign Language Interface 
(FLI) for the same reason. The simulation engine described 
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In David A. Burgoon. A mixed- language simulator for 
concurrent engineering* In The Proceedings for the 1998 
International Verilog HDL Conference and VHDL 
International Users Forum, US^ March 1998. IEEE Computer 
Society is also capable of oo- simulating C models with 
lower level Verilog Models. These particular methods 
apply only when the high-level hardware is described in 
a sequential language such as c. Further, the c code must 
be written in a special atimulue -response fashion^ which 
is not purely algorithmic. 

SUMMARY OF THE INVENTION 

According to a first aspect of the invention, there is 
provided a method of co-simulating a digital circuit using 
a simulation engine which communicates with at least one 
first programming language by means of a foreign language 
interface and which communicates directly with at least 
one second programming or hardware description language, 
comprising the steps of : 

(a) providing at least one first model of at least one 
first part of the digital circuit in at least one 
high-level hardware description language which supports 
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concurrent procei^ses coininunloatlng with eaoti other; 

(b) converting the at least one first model to at least 
one software model in the at least one first language; 

5 

(c) providing at least one second model of at least 
one second part of the digital circuit in the at least 
one second language; and 

10 (d> applying the at least one software model in the 

at least one first language and the. at least one second 
model In the at least one second language to the simulation 
engine . 

15 A high-level or hehavioural hardware description is a 
description of a hardware component which specifies only 
the behaviour of the component and does not specify its 
physical architecture, such as the logical, arithmetic 
and storage components of which it is constituted, the 

20 clock rate and its t±ming. The behaviour Is usually given 
e.B an algorithm- A high-level or behavioural hardware 
description language is a language in which the high- 
level description of the hardware can be described. 
High-level or behavioural hardware synthesis or 
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compilation is the process of generating a hardware 
low-level description from a high-level hardware 
description. Given a clock rate^ this process infers the 
required logical, arithmetic and storage components, the 
5 signals connecting them, their timing and controlling 
logic. 

The converting step (b) may comprise compiling the at 
least one first model in the at least one high-level 
10 hardware description language to the at least one software 
model in the at least one first language* 

The at least one high-level hardware description language 
may he hased on a communicating sequential processes 
15 model. 

The at least one first part of the digital circuit may 
be represented xn the at least one high-level hardware 
description language as a plurality of concurrent 
20 processes which communicate with each other and the 
converting step <b) may comprise converting the 
concurrent processes to a sequential software process. 
The software process may comprise at least one stimulus 
unit for detecting a predetermined stimulus and at least 
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one rdsponse unit for providing a predetermined response 
In response to the at least one dtlmulus unit* At least 
one of the response units may comprise a process response 
unit for performing a desired behaviour of the at least 
5 one first part of the digital circuit. The desired 
behaviour may comprise a. plurality of discrete processes 
triggered by a common event and the process response unit 
may comprise a scheduler for scheduling the dita crate 
processes and a process handler for performing the 
10 discrete processes in accordance with the scheduling. 
The scheduler may: form a list of active unhandled 
processes having respective exit points; choose from the 
list a current process; and select an entry point for 
the current process. 

15 

At each exit point, the scheduler may choose from the list 
a further current process and may select a further entry 
point for the further current process » 

20 The converting step (b) may comprise: generating, for at 
least one of the discrete processes « software code 
including a program loop having a jump Instruction and 
a loop termination condition; analysing the loop 
termination condition to determine whether it is possibly 
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non-terminat±ng; and, ±f so replfiicsing the Jump 
Inetruotlcn with an exit point • 

At the exit point, the scheduXer may place the at least 
5 one aisorete process in the list of active unhandled 
processes with a new entry point. 

According to a second aspect of the invention, there is 
provided a method of designing a digital circuit, 
10 comprising performing a method according to the first 
aspect of the invention, checking whether the result of 
the CO- simulation is correct^ checking whether the 
digital circuit is synthesiaable, and generating a 
low- level hardware description of the digital circuit. 

15 

According to a third aspect of the invention, there is 
provided a method of manufacturing a digital circuit, 
comprising performing the method according to the second 
aspect of the invention and forming, from the low- level 
20 hardware description, an Integrated circuit including the 
digital circuit • 



According to a fourth aspect of the invention, there is 
provided an integrated circuit made by a method according 
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to the third aspect of the invention. 

According to a fifth aspect of the invention, there is 
provided an apparatus for- performing a method according 
5 to the first or second aspect of the invention* 

The apparatus may comprise a computer progreunmed by a 
computer program. 

10 According to a sixth aspect of the invention^ there is 
provided a computer program for an apparatus according 
to the fifth aspect of the invention. 

According to a seventh aspect of the invention , there is 
15 provided a storage medium containing a program according 
to the sixth aspect of the Invention. 

In the present method^ a high-level sequential 
description of a synchronous hardware model can he 
20 generated automatically from a high-level hardware 
description based on a concurrent model of computation* 
The model description can be compiled into executable code 
and can be co-simulated with other system components. We 
therefore, achieve the advantages of both high-level HDL 
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simulation and compilation baaea elmulatlon for the 
oo-simuXation of a high-level hardware description with 
other system components. 

An example of the use of this method is to co- simulate 
a hardware circuit descrlhed as an algorithm in a 
CSP-hased high-level language with other system 
components during system design and development. For 
example, this method can be used for the fast co- 
simulation of hardware circuits described in the Bach C 
language with other system components. Figure 1 of the 
accompanying drawings illustrates the Bach hardware 
design flow, where hardware is described in the Bach 
high-level language, and a low- level synthesisable 
hardware description is generated automatically. Since 
the hardware designer uses a high-level language instead 
of a lower level one (such as VHDL) , the design process 
is much quicker and therefore cheaper than traditional 
hardware design processes. The use of the present method 
allows the co- simulation of the hardware component to be 
done at the algorithm- level and is therefore much faster 
than a co- simulation process where lower-level hardware 
descriptions are used. As a results the time spent in 
hardware design is reduced. 
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The advantages o£ this method Include t 

(a) allowing the co- simulation of the hardware 
component to be done at the 

algorithm -level and therefore i 

<i) the simulation is independent of the target 
arohiteature; 

(11) the simulation is muah faster than 
simulations at lower levels sinoe the amount of detail 
that is simulated is much less. 

(h) The component model can be compiled into the 
native code of the machine used for simulation from an 
algorithmic description. This approach offers very high 
simulation speeds . 

(c) The generation of the hardware component model 
used for simulation does not require complex pre- 
computatlons and Is therefore quite efficient, 

(d) It is often desirable to co-simulate a hardware 
description with other system components during the early 
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Stages of hardware development, that is, before an 
efficient and fully synthesisable hardware description 
has been developed. Since the hardware description used 
£or oo- simulation does not need to be syntheeieed into 
lower level descriptions, this oo- simulation method oan 
be used during these early stages of the design flow. 

The above factors all contribute to the advantages 
associated with high-level hardware (and system) design 
flow: 

(A) quicker time-to-market , 

(B) and the ability to explore a large design space 
and hence develop more efficient designs. 

The invention will be further described, by way of example , 
with reference to the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates the design flow of hardware using 
a high-level language and including a method of 
constituting an embodiment of the invention; 
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Figure 2 Illustrates a known method In which the 
high-level description is first used to generate a lower 
level target model which is then used for co- simulation? 

5 

Figure 3 shows a general view of a system description with 
component model descriptions communicating with each 
other and with some component models described In a 
high-level language? 

10 

Figure 4 shows a specific example of a system description 
comprising component model descriptions communicating 
with each other and with some component models described 
in the Bach C high-level language; 

15 

Figure 5 shows the simulation of the system description 
using a simulation engine with means for the simulation 
models to communicate with the simulation engine; 

20 Figure 6 shows a high-level model described as processes 
communicating together and with the environment and 
accessing internal or external devices: 

Figure 7 shows the Interface of the target hardware model. 
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Which ±s also the Interface of the simulation model? 

Figure 8 shows the simulation model which processes the 
input values, returns output values and is stimulated by 
a number of stimuli; 

Figure 9 illustrates the overall method used for 
generating the simulation model using a simulation model 
generator^ a compiler and a simulation engine; 

Figure 10 illustrates the overall method used for 
generating the simulation model for the particular 
example shown in Figure 4; 

Figure 11 shows three kinds of storage that the simulation 
model can access; 

Figure 12 illustrates the structure of the simulation 
model ; 

Figure 13 shows the reset response unit of the simulation 
model; 

Figure 14 shows the internal device response unit of the 
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Simulation moael; 

Figure 15 shows the process response unit of the 
simulation model; 

5 

Figure 16 shows a proaess list used by the scheduler of 
the simulation modelj 

Figure 17 shows a mechanism used for scheduling and 
10 selecting the current entry point; 

Figure 18 shows a pre-compiled simulation model 
generation unit? 

IS Figure 19 shows a simulation model code processor and 
generator ? 

Figure 20 shows a process response unit generator of the 
simulation model code processor and generator; 

20 

Figure 21 shows the code generation of sequential 
composition ; 

Figure 22 illustrates parallel composition; 
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Figure 23 shows the code generated from parallel 
composition; 

Figure 24 shows the code generation of loops that 
definitely terminate; 

Figure 25 shows the code generation of loops that may not 
terminate ; 

Figure 26 shows the generated code for sending value 
through an external channel? 

Figure 27 shows a block for activating a process waiting 
for data to be sent through an external channel; 

Figure 28 shows the generated code for receiving value 
through an external channel: 

Figure 29 shows a block for activating a process waiting 
for data to be received through an external channel; and 

Figure 30 shows the criterion used for assigning instance 
local locality to data in the simulation model* 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present method can taKe a textual description of a 
high-level hardware design and generate a aomponent model 
that can oommunioate with a eimulation engine. This makes 
use of a simulation engine and a means for the system 
component models to communicate with the simulation 
engine, An example of such means is described in 
US 5335191. By using such communication means and a 
simulation engine^ the present method allows high-level 
hardware designs to be co- simulated with other system 
components . 

The high-level hardware description language is assumed 
to be based on a model of computation which considers 
concurrency (parallelism) and is therefore not purely 
sequential. Some embodiments make use of the 
Communicating Sequential Processes (CSP) model, but this 
method may be applied to any model of . concurrency- A 
description based on the CSP model describes a parallel 
algorithm involving a number of sequential processes 
communicating with each other using synchronous channels . 
The parallelism is stated explicitly using a special 
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language construct (typically the par or PAR construct) . 
The synchronous oommunioation is also stated explicitly 
in the sequential processes toy the send (or I ) and receive 
(or ?) oonstruota. The sequential processes can be 
structured using the usual constructs of an imperative 
programming languages sequential composition, 
conditionals and loops. 

The CSP model is used to describe a hardware component 
which needs to coramunioate and react with Its environment. 
This is done through synchronous communication using 
channels, or else by certain devices. The devices are 
memories s RAMs. ROMs and registers, and can be either 
internal (described in the CSP model) or else external 
(In the environment ) 4 Figure 6 illustrates a hardware 
component 10 described as a CSP model structured as seven 
processes 11 to" 17 communicating with each other and 
accessing internal and external devices 18,19. Figure 
7 illustrates the Interface of the low- level target 
hardware model 20 specified by the CSP-based high-level 
model. It is a synchronous circuit and includes ports 
for external clocks, initialisation, reporting status, 
synchronous external communication, and access for 
internal and external devices. 
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The oomponent moael that is automatically constructed by 
this method for co -simulation (the simulation model) is 
described as a sequential algorithm which contains a 
ntimber of communication instructions for asynchronous 
communication with the simulation engine. A number of 
the input communications are considered to be stimuli to 
the component model i they instruct the model to perform 
some action which basically consists of reading some input 
data, processing it, changing the internal state of the 
model, and sending some output data. Figure 8 shows the 
external inputs and outputs of the simulation model 21. 

Figure 12 shows the overall structure of the generated 
simulation model which comprises an initialisation unit 
24, a finishing unit 25 and several stimulus units 26 and 
response units 27. There is a stimulus unit 26 for each 
type of input stimulus which the simulation model accepts. 
The stimulus unit 26 decides whether to activate a 
corresponding response unit 27. The following are 
examples of response units s 

(a) A reset response unit which sets the internal 
State of the model to its initial value. The 
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corresponding stimulus is the active value of the reset 
port. 

<b) Internal devices response units which handle the 
internal devices. These handle the representation of the 
registers, RAMs^ ROMs, etc. and are stimulated by the 
values o£ the input ports for the case of asynchronous 
devices and by clock edges for the case of synchronous 
devices . 

(c) Process response units which perform the actual 
behaviour described by the high-level hardware 
description and represent the processes of the high-level 
CSP model. Since the high-level model represents a 
synchronous circuit, the process response units are 
stimulated by clock edges. Because of the parallelism 
described by the high-level model, the process response 
unit includes a mechanism for scheduling the tasks 
representing the sequential processes* 

The method by which the simulation model is generated from 
a textual description of the hardware component consists 
of the following steps: 
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< 1 ) generate a siinulatlon model desar±pt±on using a 
simulation model generator; 

(2) compile the simulation model using a standard 
compiler • 

The compiled simulation model can then be used by the 
simulation engine during co- simulation ♦ 

The structure of the Simulation Model Generator is similar 
to that of a compiler and comprises a parsing unit, a code 
processing and generation unit, and a code printing unit. 
The code processing and generation unit takes the internal 
representation of the parsed high-level model, and 
generates the internal representation of the simulation 
model. It comprises the following units: 

(1) stimulus selectors which assign devices and 
processes to particular stimuli; 

(2) response unit generators which generate the 
individual reset, internal devices and processes response 
unit from the given CSP hardware model; 
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( 3 ) and an overall Code Generator whioh constructs the 
simulation model description from the individual response 
units . 

The process response generation unit is the most 
significant component of the simulation Model Generator 
and is responsible for: 

(a) seguentialising the parallel algorithm described 
by the CSP model? 

(b) generating code for the synchronous channel 
Gommunloatlon ; 

(c) generating code for the access interface for 
external devices; 

(d) assigning locality to the data of the CSP model. 
For instance^ this unit decides whether certain data can 
be shared by all instances of the seune model or not, 

<e) generating a scheduler to take care of the 
parallelism described by the processes in the CSP model- 
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The present method can b© used in the simulation of a system 
description in which a number of the system components 
are described in a CSP-based high-level hardware 
description language • The design flow for such a system 
is shown in Figure 1 where the CO -simulation of the system 
components is an important procedure for verifying the 
behaviour of the system design. 

High-level hardware descriptions are implemented at 30 
and result in Bach source code. Other system components 
descriptions are developed or acG[uired at 31 and these, 
together with the Bach source code, are used at 32 to 
CO- simulate the high level hardware descriptions with the 
other system components. At 33, the oo- simulation result 
is checked and, if It is not correct, the step 30 is 
repeated so as to change the high-level hardware 
descriptions* If this co-simulation result is correct, 
a test 34 determines whether the resulting circuit 
description is capable of being synthesised. If not, the 
control returns to the step 30. If the circuit description 
is aynthesisahle, a step 35 generates a low- level hardware 
description and performs the synthesis which ultimately 
results in the manufacture of an integrated circuit or 
silicon chip 36 * 
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Figure 3 Illustrates an example of the system description 
40. The system desariptlon comprises a number of 
components) 41 to 44 described at different levels of 
5 abstraction, with some of the component models 41, 42 
described in a high-level language. 

The simulation mechanism involves the generation of 
simulation models from the component model descriptions 
10 and then co-simulating them using a simulation engine. 
As shown in Figure 5, the simulation engine 45 
communicates with simulation models 46 to 49 which 
correspond to the descriptions 41 to 44, respectively, 
of Figure 3* 

15 

The high-level hardware models are described in a language 
based on the CSF model of computation. Figure 6 shows that 
each of these models comprises a nx:unber of sequential 
processes 11 to 16 communicating with each other using 
20 synchronous channels. The processes 11 to 16 can 
communicate with external resources using synchronous 
channels, or by accessing devices 18 to 19. In this 
embodiment, the devices are registers, RAMs and ROMs, but 
in general this method applies to any I/O devices (e.g. 
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displays^ sensors^ eto). The devices (18, 19) can be 
Internal (In the model) or external (In the environment) • 
The inodel can also provide aocesEs to a number o£ Its 
Internal devices to the environment, 

5 

A high-level CSP model describes a hardware component. 
An example of the target hardware component model 20 Is 
shown In Figure 7. This model has ports to represent the 
external synchronous aommunlcatlon channels and access 

10 to the Internal and external devices « The target model 
20 represents a synchronous hardware component and 
therefore Includes ports for external clocks • Other 
ports for Initialising the circuit and for reporting its 
internal status are Included, In this embodiment, we use 

15 the example of a reset port which resets the circuit to 
an initial state and a finish port which reports whether 
the circuit is at the final state or not • The simulation 
model which will be used for oo-simulatlon should have 
the same behaviour as the target hardware model (which 

20 is used for synthesis and fabrication). 



As shown in Figure 9, the mechanism for generating the 
simulation model comprises a simulation model generation 
unit 50 and a compiler 51 « The model generation unit 50 
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takes the high-level model description and returns a 
siznulatlon model description. The automatically 
generated simulation model is described in a standard 
imperative language such as C. The simulation model is 
5 then compiled using a standard compiler 51 for the 
language used to describe the generated model. An 
illustration of this method on the specific example shown 
In Figure 4 Is shown In Figure 10. 

The CO- simulation method requires a simulation engine 45, 
and a means for the system component models 2 to 6 to 
communicate with the simulation engine 45. An example 
of such means is described in US 5335191, the contents 
of Which are Incorporated herein by reference. When 
using such communication means, the simulation model is 
activated by a number of stimuli and takes a number of 
inputs and returns a number of outputs as illustrated In 
Figure 8. 

20 Like any other computer code, the code 52 of the compiled 
simulation model uses data, stored in memory. Figure 11 
illustrates that the simulation model uses three kinds 
of data storage: 
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(a) Temporary storage 53s th© data stored here can be 
accessed quickly. 

(b) Model-Local storage 54s the data stored here has 
5 fast access as well, but It Is used by all Instances of 

the same simulation model. 

(c) Inetance-Local storage 55: this storage is 
allocated Individually for every simulation model 

10 instance. Access to this storage Is more computationally 
expensive than the access to the temporary and model- 
local storage 53, 54. 

An instance-local data object called the execution mode 
15 is used by all simulation models. This data can have one 
of the following values s 

(1) Uninitialised: the simulation model has not been 
initialised by the reset signal yet. 

20 

(2) Running: the simulation model has been 
Initialised and has not reached the final state. 

(3) Finished: the simulation model has reached its 
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final estate. 

When the simulation model is created^ the initial value 
of the execution mode is Uninitialised. We say that the 
5 uninitialised flag is set. Similarly we say that the 
running flag or the finished flag is set depending on the 
value of the execution mode. 

Figure 12 shows the structure of the generated simulation 
model. This model comprises the initialisation unit 24, 
the finishing unit 25^ and several stimulus and response 
units 26, 27. The initialisation and finishing units 24, 

25 perform a number of book-keeping tasks* For example 
the initialisation unit 24 is responsible for fetching 
the instance-local storage when the simulation model is 
activated and the finishing unit 25 is responsible for 
recording the instance-local storage so that it can be 
retrieved later. The simulation model contains a 
stimulus unit 26 for each different kind of stimulus that 
can be accepted by the model. For every stimulus unit 

26 there Is a response unit 27. When the stimulus unit 

26 detects a stimulus, it activates its associated 
response unit 27, The different kinds of response units 

27 includes 



10 



15 



20 
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(a) a reset response unit wlxlafii sets the internal 
state of the model to its initial value* 

5 (b) internal devices rasponae units which handle the 

internal devices. 

(c) process response units which perform the actual 
behaviour described by the high-level hardware 
10 description and represent the processes of the high-level 
CSP model. 

Figure 13 illustrates the reset response unit. When this 
unit is activated, it sets (57) the values of specific 

15 initial-local data to their initial value (as described 
in the high-level model) • It also sets (58) the output 
port signals to their initial values as intended by the 
high-level description, for example setting all the 
external device interface and external communication 

20 ports so that the circuit is not accessing external 
devices or trying to communicate with external resources. 
It then sets the running flag 59 to indicate that the model 
has been initialised. The corresponding stimulus unit 
of the reset response unit checks whether the reset port 
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has thd act±ve value* 

The internal device response unite comprise device 
handlers 60 which model the appropriate behaviour of the 
5 devices whenever they are activated as shown in Figure 
14 « The corresponding stimulus units either check whether 
the values o£ the input ports have been changed in the 
case of asynchronous devices or check the appropriate 
clock edges in the case of synchronous devices. 

10 

The process response iinits handle all the model processes 
that are stimulated by the same clock. In the ease of 
a single clock target models all the processes of the model 
are handled by the same process response unit. Figure 

15 15 shows the structure of a process response unit which 
comprises a mechanism 61 for checking the running flag, 
a scHeduler 62 and a process handler unit 63 • The scheduler 
62 takes care of the parallelism described in the 
high- level hardware model. The process handler unit 63 

20 represents the behaviour of the associated processes. A 
number of locations to the process handler code are called 
entry points and are locations ±n wh±cl:i the scheduler can 
transfer execution. Another number of locations In the 
process handler code are called exit points and are 
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locations from whicah execution can be transferred back 
to the scheduler. The scheduler 62 decides on an 
appropriate entry point in the process handler unit 63. 
The process handler unit 63 is then executed until an exit 
point is reached, in which case execution returns to the 
scheduler 62. The stimulus units corresponding to process 
response units check the appropriate clock edges. 

The scheduler 62 decides on an entry point in the process 
handler unit 63 by using a process list as shown in Figure 
16, The process list is stored in instance- local storage 
and comprises a list of process records. Each process 
record contains the following information t a process 
identifier ? status information; and an entry point 
location. No two process records in a process list can 
have the same identifier. The status Information 
indicates whether a process is running or not, and whether 
it has already been handled by the scheduler 62 or not. 
Therefore, the process status is either active (also 
called running) or inactive (also called sleeping) . The 
scheduler 62 ensures that all the active processes are 
handled at least once, and that each scheduling stage 
exits after a finite amount of time. In this embodiment, 
the scheduler 62 handles each active process exactly once , 



- 36 - 



O0R00416 



A different approach la to repeat the scheduling mechanism 
a finite number of times , or until the prooesG list becomes 
empty - 

The mechanism for handling each active process exactly 
once Is as follows: Active processes can either be handled 
or unhandled. One of the active unhandled processes Is 
called the current process. 

The scheduler should be able to perform these functions: 

(1) Set all active processes as unhandled* 

(2) Check whether there are active unhandled 
processes In the process list. 

(3) Select an active unhandled process as the current 
process* 

(4) Find the entry point of a giveu process. 

(5) Set the current process as h2mdled and set Its 
entry point to a given location. 
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(6) Deactivate the current process and set its entry 
point to a given location, 

(7) Remove the current process from the process list. 

5 

(8) Activate a specific inactive process. 

(9) Create a new active process and select it as the 
current process. 

10 

(10) Create a new unhandled process and set its 
entry point to a given location. 

Figure 17 illustrates the scheduling mechanism used for 
15 selecting an entry point in the process handler unit 63- 
The scheduler 62 starts by activating 64 a number of 
sleeping processes « depending on the input values to the 
simulation model. For example^ if a process was inactive 
because it was waiting for a specific input port value, 
20 then the scheduling mechanism tries to checlc this input 
port value and decide whether to activate the sleeping 
process or not. The active processes, if any, are then 
marked 65 as unhandled. The scheduler 62 checks 66 
whether the process list contains any unhandled active 
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processefi, and selects 67 one of them as the current 
process. The entry point given ±n the current process 
record is then used 68. Vhe execution of the process 
response unit is transferred to this entry point in the 
5 process handling unit, which keeps running until an exit 
point is reached. Note that the process handling unit 
63 can use some of the scheduling functions and the current 
process Is usually either set to unhandled, deactivated 
or removed from the process list just before the exit point 
10 is reached « At this points execution returns to the 
scheduler 62 and a new current process and entry point 
are selected. This is repeated until no unhandled active 
processes are left in the process list. 

15 This concludes the description of the simulation model 
which is generated automatically from the high-level 
hardware model. The following describes the simulator 
model generator 50 which« as illustrated in Figure 9, is 
used to generate a simulation model description. The 

20 compiler 51 is then used to compile the model. 



Figure 18 shows that the simulation model generator 
comprises the main components usually used in standard 
compiler technology (see, for example, Alfred V. Aho, Ravi 



t 
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Sethi and Jeffery D, Ullman, * Compilers: Principles, 
Techniques , and Tools . " Addison Wesley Publishing Company, 
October 1985} s 

5 (a) A lexical analyser and parser 70 which take the 

textual description of the high*- level hardware model and 
generate an internal representation of the same. 

(b) A hardware model code processing and 
10 generation unit 71 which takes the internal description 

of the high-level hardware model and generates an internal 
representation of the simulation model, 

(c) A code printer 72, which generates a textual 
15 representation of the simulation model from its internal 

representation . 

The simulation model generator uses standard technology 
for the lexical analyser and parser 70, and for the code 
20 printer 72. The hardware model code processing and 
generation unit, is shown in detail in Figure 19 and 
comprises a port selector and interface generator 73, a 
stimulus unit generator 74 and a response unit generator 
75 for all the different types of stimulus /response units 
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and an overall simulator model code builder 76. 

The port selector and Interface generator 73 generates 
the interface of the simulation model from the interface 
of the high-level model • The interface of the high-level 
model describes the ahannels that are used for external 
communication, the access given for internal devices « and 
the access required for external devices* The interface 
of the slmuiatlon model should be the same as the interface 
of the target hardware model 20 used for synthesis as 
shown in Figure 7 and comprising the input and output ports 
of the model. The ports generated by the interface 
generator are as follows s 

(1) Inlt/Status ports: a reset input port signal 
is used to reset the simulation models and a finish output 
port is activated by the simulation model when the 
simulation model reaches its final state. 

(2) External Channel Communication ports: these are 
used for synchronous communication with other system 
components and comprise a two-way handshake communication 
mechanism with one data port, and two handshaking ports t 
a sender_ready and a receiver_ready port. The 
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oommunioation is synchronised when both the sender^ready 
and recelver_ready port signal are active , At this point , 
data is transferred from the sender to the receiver 
through the data port. 

5 

(3) Internal Device Aooeaa porta: these porta 
correspond to the usual interface of device blocks. For 
example, an SRAM device will have the usual address and 
data bus ports ^ write-enable and read-enable ports, 

10 possibly write -acknowledge and read- acknowledge ports, 
and a clock port if it is a synchronous RAM. 

(4) External Device Access ports: again, these 
ports correspond to the usual interface of device 

15 blocks - 

The overall simulation model code builder 76 generates 
the simulation model from its individual components 
generated by the stimulus and response unit generators 
20 74, 75. Figure 12 shows how the simulation model is 
constructed from the stimulus /response units 26, 27 
together with initialisation and finishing units 24,25. 
The initialisation and finishing units 24, 2S are trivial 
book-keeping units which depend on the simulation engine 
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and the communication mechanism used between the 
simulation engine and the component models. 

The reset response unit generator builds the reset 
5 response unit having the structure shown in Figure 13. 
The block initialising the instance local data is 
generated by taking the initialisers from the internal 
representation of the hardware model and then generating 
the instructions required to initialise them. The block 

10 initialising the signal values is generated by taking the 
output ports selected by the interface generator and 
generating instructions to initialise them. The 
appropriate instruction(s) to set the running flag is then 
generated. The reset stimulus unit generator simply 

15 builds a unit which checks the value of the reset input 
port. 

The internal device response unit generator lists all the 
internal devices that can be accessed by the environment 
20 and creates a response unit for each of them which simply 
models the standard behaviour of the device. The 
internal devices are represented in the simulation model 
by appropriate data structures j RAMs and ROMs are 
represented by arrays and registers are represented by 
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:Lnstanoe local variables « The device response unit 
models the appropriate behaviour: read access to a RAM 
or ROM Is modelled by array Indexing; write access to a 
RAM is modelled by array element assignment; read access 
5 to a register is modelled by variable access; and write 
access to a register is modelled by variable assignment. 
The internal device stimulus unit generator creates the 
appropriate unit which either checKs the appropriate 
clock signal value in the case of synchronous devices or 
10 a change in the input signal values in the case of 
asynchronous devices. 

The main part of the model code processor and generator 
is the process response unit generator, which is shown 
15 in Figure 20 and which comprises: 

(a) a sequential code generator 80, responsible for 
creating a sequential version of the parallel algorithm 
given in the high-level model? 

20 

(b) A channel communication code generator 81, 
responsible for generating the instructions responsible 
for the communication between processes and the external 
environment ; 
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(o) An external device access code generator 62, 
responsible for generating the Instructions to access 
external devices correctly; 

5 

(d) A data locality asslgner 83, responsible for 
assigning tbe appropriate locality to the data in the 
simulation model which represents the data in the 
high-level model • 

10 

(e) A scheduler generator 84^ which generates the 
scheduling functions. 

The sequential code generator 80 starts by analysing the 
15 internal representation of the high-level model and 
builds an Internal description of the sequential code of 
the process 

handler unit shown in Figure 15. When a communication 
instruction is encountered, the channel communiaatlon 
20 code generator 81 builds the appropriate instructions to 
model the oommunioatlon. Similarly, when an external 
device access Instruction is encountered, the external 
device access code generator 82 generates the appropriate 
instructions to perform the device access. The Internal 
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representation of the process handler unit is then 
analysed by the data locality assigner 83 in order to give 
an appropriate locality to each data Item. Finally, the 
scheduler generator 84 takes the internal representation 
5 of the process handler unit 63 and generates the process 
response unit by creating the scheduler 62 . 

The sequential code generator 80 builds the required 
sequential code by analysing the structure of the 

10 high-level model. The high-level model is based on a 
parallel algorithm and is therefore composed from 
sequential instructions by parallel composition and 
sequential constructs such as sequential composition and 
loops . With the exception of communication and external 

15 device access, the individual (atomic) sequential 
instructions in the high-level model can be used to 
generate the sequential instructions in the simulation 
model using some known method. Examples of these atomic 
instructions include arithmetic expressions and 

20 assignments. Given this method we now show how the 
structure of the high-level model is used to build the 
required sequential code. We therefore show how code 
composed by: 
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(1) 



Sequential Composition; 



(2) 



Parallel Composition? 



(3) 



Loops 



U 10 

CO 

ii 15 



is treated to generate the sequential code In the process 
handler unit. 

Sequential Composition Is treated very simply, as shown 
in Figure 21. If a process consists of several processes: 
HI, H2^ - . . / Hn sequentially composed together^ then the 
required sequential code Is generated by: 

(a) generating the sequential code SI, S2, 

Sn for each of the processes HI, H2, ... , Hn 

(b) Building the required sequential code by 
composing SI, S2 j , Sn sequentially in the right order. 

Parallel Composition is treated in a more complex way. 
Figure 22 shows a process composed of a number of processes 
HI, H2, Hn in parallel. For ease of explanation, 

we assume that this process is then composed sequentially 
between Hb and Ha* Figure 22 shows the resulting 
sequential code which is generated from the blocks of 
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fioquentlal code SI, S2, Sn and other instructions* 

The blocks Si, S2, . . . , Sn aire the sequential code blocks 
generated from the high-level processes HI, H2, Hn, 
Similarly, Sb and Sa are generated from the processes Hb 
5 and Ha. The following points about the generated 
sequential code should be noted s 

(1) Each of the blocks SI, S2, Sn with the 
exception of Sn is followed by a jump instruction to the 
block starting with ^setting terminated flag*'. Block 
Sn does not need such a jump instruction. 

(2) A new process for each of the sequential 
blocks SI, S2, Sn is created. These are also called 
SI, S2, Sn here; Similarly, the process names Sb 
and Sa are used. 

( 3 ) Each of the blocks S2 , .... Sn is labelled with 
an entry point. The generated sequential code contains 

20 one exit point. 

(4) Apart from the blocks SI, S2, Sn, the 
sequential code also contains calls to a number of 
scheduler functions, and the following three kinds of 
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instructions t 

(i) setting non-terminated flag for a number of 
processes; 

(ii) setting terminated flag for the current 
process in a number of processes; 

(ill) GhecXing whether all the processes in a 
given number of processes have the terminated flag. 

These instructions are used for the synchronisation 
mechanism required to start executing the code in Sb only 
after all the code in SI, S2, . . Sn has been executed. 
These instructions are explained below • 

For each list of processes SI, S2, , Sn representing 

a list of high-level processes composed in parallel, an 
Instance local data structure called the terminating 
flags is generated. This data structure is used to 
indicate that all the processes have just been activated, 
to indicate that one of them (the current) has just been 
deactivated, and to check whether all of them have been 
deactivated. There are several easy and cheap ways to 
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implement these instructions. An example is to use an 
Integer i for the data structure, and then 2 

(a) setting non- terminating flag for SI, . . . , Sn 
5 is implemented by setting the value of ± to n 

(b) setting terminating flag for current in 
SI, . • Sn is implemented by decrementing the value of 
I 

10 

(c) checking whether all Si, ...^ Sn have 
terminated is implemented by checking whether i is 0. 

In general loops consist of an expression to check the 
15 termination condition of the loop, and the body of the 
loop* The sequential code generator: 

(1) generates the sequential code for the 

termination condition (which we can call the S-condition) 
20 from the high-level code for the same condition (which 
we can call the H-condition) , It also generates the 
sequential code for the loop body (S^-body) from the 
high-level code of the body (H-body) ■ 
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(2) Analyses the loop to cheok whether it is 
possibly non- terminating^ or whether it definitely 
terminates. Methods for checking whether a loop 
definitely terminates Includes 

S 

(a) checking whether the loop represents a 
standard for loop (that la, a counter is set to an initial 
value, the terminating condition checks whether the 
counter has reached a max/mlnvalue, and the counter Is 
10 Increased/decreased monotonically at each execution of 
the loop body) • 

(b) checking whether every execution of the 
S-body reaches an exit point. 

15 

(3) If a loop definitely terminates^ then a 
similar loop is created by replacing the H-condition with 
the S-condltion, and the H-body with the S-body. Figure 
24 shows this for the case of loops where the terminating 

20 condition is checked before the execution of the loop* 

(4) If a loop may not terminate, then the beginning 
Of the loop is marked with an entry point, and the jump 
Instruction used for repeating the loop Is replaced by 
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an exit point anca an instruction to set the current process 
as handled. An example of this is shown in Figure 25 ♦ 

After generating the internal representation of the 
5 simulation model, the sequential code generator 80 adds 
the instruction(s} to set the finish output signal to 
active, and to set the finished flag at the end of the 
code of the model. 

10 The channel communication code generator 81 generates the 
instructions to model the inter-process communication 
constructs. Standard methods used for sequentiallaing 
CSP-based parallel algorithms can be used to model the 
communication between two internal processes. We 

15 therefore concentrate on the description of the method 
used for modelling the communication between an internal 
process and the external environment* The interface for 
external communications channels is assumed to contain 
a recelver^ready signal, a sender^ready signal, and a data 

20 signal and data is transferred when both the 
reoeiver_ready and sender_ready signals are active. 

For each external channel o in the high-level model, an 
instance local variable c-process is generated. This 
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var±able aan contain the process identifier for each 
process in the simulation models together with the value 
none. The none value is also the initial value of the 
o-prooess variable. The none value is used to represent 
5 the state where no process 

is waiting for data to be transferred through the channel 
c. A value corresponding to an identifier for a process 
p is used to represent the state where the process p is 
waiting for data to be transferred through channel c. 

10 

The channel communication code generator 81 generates two 
blocks of code for each communication instruction. One 
block is inserted in the process handler unit 63 and 
replaces the communication instruction in the high-level 
15 model • The other block is appended to the block in the 
scheduling unit 62 that activates sleeping processes as 
shown in Figure 17, 

We consider the two communication instructions: sending 
20 a value through an external channel^ receiving a value 
through an external channel, 

A communication instruction to send a value through an 
external channel c is replaced by the code shown in Figure 
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26, whiGh transfers the value through the data channel 
sets the »ender_ready signal to high sets the c-process 
variable to the current process and then deactivates the 
current process and exits. The code which re-actlvates 
the process after data has been received. is shown in Figure 
27 and is inserted in the activate sleeping processes 
block of the scheduling unit. The code shown in Figure 
27 checks whether a process is waiting for data to be 
transferred through the channel c and whether the 
receiver_ready signal is active In which the waiting 
process in the c-procese is activated, setting the c- 
process variable back to none and the sender_ready signal 
back to inactive. 

A communication instruction to receive a value through 
an external channel c is replaced by the code shown in 
Figure 28* We assume that the transferred value Is to 
be stored in a storage location given by lvalue. The 
generated code sets the reoeiver_ready signal to high^ 
sets the c-proceas variable to the current process and 
then deactivates the current process and exits. When the 
process is activated again, it receives the value from 
the data signal and stores it in lvalue- The code which 
re-activates the process after data has been received is 



- 54 - 



00R00416 



shown In Figure 29 and Is Inserted In the activate sleeping 
processes block of the scheduling unit. The code shown 
m Figure 29 checks whether a process Is waiting for data 
to be transferred through the channel c and whether the 
sender_jready signal is active, in which case the waiting 
process in c-prooess is activated^ setting the c-process 
variable back to none and the receiver_ready signal back 
to inactive. 

The external device access code generator 82 builds 
similar blocks to handle external device access, and these 
are not described in detail here. Basically, an instance 
local variable is used to check whether a process is 
waiting for the effect of the device access or not. The 
external device access code generator 82 replaces the 
device access instruction in the high-level model with 
a block of code in the process handler unit 63 which sets 
the appropriate signals to perform the device access and 
then sets the value of the process to the current process, 
deactivates the current process, and then exits. When this 
processes is activated again, the generated code uses the 
effect of the device access (if any) appropriately. Also, 
the external device access code generator 82 generates 
a block of code to check whether the effect of the device 
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access occurred and then re-actlvates the process 
waiting for this affect. This code block is appended to 
the activate sleeping processes block of the scheduling 
unit • 

The locality asslgner 83 aseigns one of the following 
three localities to the data in the simulation model 
representation that represent the data in the high-level 
model representation: 

(I) temporary, 

(II) model local, 
(ill) instance local 

The locality asslgner 83 assigns the model local locality 
to all constant data; for exzunple to the data representing 
the values of ROM devices. Instance local locality is 
given to data that is written before an entry point, and 
then read after an entry point, as illustrated in Figure 
30. The rest are then given the temporary locality if 
they represent local high-level model data or the model 
local locality if they represent global high-level model 
data. This method as used by the locality asslgner 83 
reduces the number of Instance local data since they are 
the most expensive to access . 



- 56 - 



00R00416 



The scheduler generator 84 performs the following two 
actions s 

(1) It generates the oode for the scheduling 

functions. It is possible for anyone knowledgeable in the 
art to design efficient implementations for these 
functions • 

( 2 ) It takes the process handler unit 63 generated 

by the other components of the model code processor and 
generator, and the block for activating the sleeping 
processes generated by the channel communication code 
generator 81 and the external devices access code 
generator 82 and then creates the scheduling unit 62 shown 
In Figure 17. 

Various other modifications will be apparent to and can 
be readily made by those skilled in the art without 
departing from the scope and spirit of this Invention. 
Accordingly, it is not intended that the scope of the 
claims appended hereto be limited to the description as 
set forth herein, but rather that the claims be broadly 
construed. 



